% ----------------------------------------------------------------------- %
% Arquivo: nsisgoettingen.tex - CAPITULO 5
% ----------------------------------------------------------------------- %

\chapter{O protocolo NSIS pela Universidade de Goettingen}
\label{c_cap_nsis}

A IETF criou o grupo de trabalho para a criação de normas e definição do
protocolo NSIS. Contudo, existem pelo menos 3 grupos de trabalho que implementam
o NSIS, sendo duas implementações em C++ (Universidade de Karlsruhe e
Goettingen, ambas na Alemanha) e uma em java (Universidade de Coimbra, Portugal).

Na Universidade de Goettingen, Alemanha, foi desenvolvida uma implementação do NSIS, o
\textit{Free Next Steps In Signaling} (FreeNSIS) inicialmente conhecido como
OpenNSIS, tendo como integrantes da implementação Xiaoming Fu, Christian Dickmann, Bernd
Schloer, Henning Peters, Ingo Juchem, Niklas Steinleitner, Hannes Tschofenig e
Andreas Westermaier, além de contribuidores.

O grupo de trabalho do FreeNSIS mantém o site
\textit{http://user.informatik.uni-goettingen.de/~nsis/} que disponibiliza
acesso a
notícias, download das versões, informações do time do projeto e resposta a
perguntas frequentes.

A implementação do NSIS pela Universidade de Goettingen, atualmente na versão
0.6.0, suporta algumas aplicações que podem ser oferecidas pelo NSIS, como as
implementações de GIST, NSLP QoS, NAT / FW NSLP e aplicações para teste de
comunicação e reserva. A maioria das aplicações são distribuídas sob a licença GPL\footnote{GNU General Public License (Licença Pública Geral), ou simplesmente GPL. A GPL é a licença com maior utilização por parte de projetos de software livre, em grande parte devido à sua adoção para o Linux.}. No entanto, a API entre GIST e as NSLPs é liberado sob a licença LGPL\footnote{GNU Lesser General Public License: A principal diferença entre a GPL e a LGPL é que esta permite também a associação com programas que não estejam sob as licenças GPL, incluindo Software proprietário.}.

Dentre os pacotes do NSIS implementado pela universidade de Goettingen, o
NSIS-QoSD (Servidor de gerenciamento de QoS), NSIS-QoS (Cliente que faz
requisições de QoS), NSIS-PING (análise da rede) e a implementação particular de
NAT/FW NSLP.

No pacote nsis contém arquivos para o desenvolvimento do protocolo, com todos os
códigos fontes, nos diretórios:
\begin{itemize}
 \item \textit{gist}: Arquivos do GIST, da máquina de estados (FSM), da API do Gist;
 \item \textit{library}: O \textit{framework}, este diretório contém classes comuns e
bibliotecas
 \item \textit{nslp}: O diretório com os arquivos fonte do NSLP, contendo a API, as
aplicações do NSIS e um modelo principal da confecção do NSIS.
 \item \textit{applications}: aplicações de teste, como o nsis-ping;
 \item \textit{bin}: diretório com os arquivos binários e o arquivo de configuração
nsis.conf
\end{itemize}

Uma das funções mais importantes é a máquina de estados do protocolo, que
gerencia as mensagens e identifica a sessão da sinalização. Cada nó QNI, QNE e
QNR tem sua máquina de estado e uma não tem ligação direta com a outra. Para
este modelo trataremos os três nós de maneira diferente, quando necessário for.

Conforme apresentado neste trabalho, o NSIS é divido basicamente em duas
camadas, sendo a camada de transporte e a camada de aplicação, com seus
aplicativos. Abriremos a camada de aplicação um pouco mais e a dividiremos em
duas camadas, figura \ref{fig:cap5_api_gist_nslp}, o protocolo com a comunicação com a camada inferior e as
aplicações que rodam sobre esta.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/API-GIST-NSLP.png}
 \caption{Estrutura de camadas NSIS}
 \label{fig:cap5_api_gist_nslp}
\end{figure}

\section{O NSLP}
Subindo ao topo da arquitetura, mostramos o funcionamento do NSIS de Goettigen a
partir da camada de aplicação até a camada de transporte. O QoS NSLP é executado
através de um \textit{daemon}, o nsis, que mantém suporte às aplicações do NSIS, que serão
executadas.

Quando executado, o \textit{daemon} do NSIS, o nsis-qosd fica escutando as mensagens
recebidas a partir da aplicação cliente local nsis-qos e de nós diretamente
ligadas a ele, partir de GIST. Ao receber uma mensagem, cria uma sessão com um
identificador. A cada nova requisição de fluxo recebido, cria um identificador
de sessão, denominado SID (\textit{session id}) e uma máquina de estados FSM (\textit{Finite
State Machine}) associada a esta sessão.

Quando geradas as mensagens a partir do aplicativo cliente nsis-qos são
marcadas para o tipo de mensagem (QUERY ou RESERVE) e para o SID. Este SID
criado é pesquisado e se não for encontrado, é criada uma nova máquina de
estados para esta sessão, relacionando o endereço com o SID, que será único
durante toda a rede.

O NSLP trata eventos com estados próprios, e alternando entre os estados
durante a troca de sinalização. Três estados estão definidos: ST\_IDLE, ST\_WR e
ST\_INST. Ao receber uma mensagem de sinalização, assume-se que o evento recebe
o estado ST\_IDLE. Neste modo a aplicação somente existe e está instanciada, não
há ocorrência e registro de estado.

Em ST\_WR a máquina de estado (FSM) espera uma resposta de uma mensagem
enviada anteriormente, mas também não há registro de reserva. Contudo, em
ST\_INST o estado da reserva é instalado e mensagens recebidas serão tratadas.
A partir da reserva, a maquina de estados gerência entre outras coisas, o tempo
da reserva.

O tempo de resposta nos nós QNI e QNE é iniciada quando uma mensagem RESPONSE
espera o envio de um QUERY ou RESERVE. Pode ser entendido como o intervalo da
sinalização a manutenção do estado. Quando uma reserva é criada, o tempo de
\textit{Refresh} nos nós QNI e QNE são iniciados e os temporizadores
\textit{StateLife} são
iniciados na QNE e QNR.  Durante o período de reserva, este tempo é atualizado
com mensagens de reserva, caso contrário, o tempo expira e o estado é
removido.

\section{O GIST}
O GIST, ou \textit{General Internet Signalling Transport}, assume que outros mecanismos
são responsáveis pelo controle de roteamento dentro da rede. O GIST é um modelo
padrão para a camada de transporte, que pode ser utilizado com os protocolos de
sinalização como o RSVP e NSIS.

A Implementação do GIST por Goettingen consiste principalmente em seis partes:
\begin{itemize}
 \item Eventos de \textit{loop}, baseados nos soquetes de conexão;
 \item Mensagem de estado de roteamento (MRS);
 \item Associação de mensagem (MA);
 \item Máquina de estados (FSM - \textit{Finite State Machine})
 \item Mensagem de análise de composição;
 \item NSLP API 
\end{itemize}

A sinalização da aplicação requer um conjunto de regras de gerenciamento de
estado, bem como protocolo de apoio para a troca de mensagens de dados ao longo
do caminho. Vários aspectos deste protocolo de apoio são comuns a todos ou um
grande número de pedidos de sinalização e, portanto, pode ser desenvolvido como
um protocolo comum.

\section{Modelo de mensagens e sugestão de alteração}
As mensagens do NSIS foram mostradas no capítulo \ref{c_cap3} deste trabalho, contudo, relembra-se que o NSIS pode efetuar sinalização de modo \textit{statefull}, mantendo o
estado nos roteadores e \textit{stateless}.

Em síntese o NSIS foi projetado para trabalhar com estas duas sinalizações,
contudo, este dois modelos de mensagens poderiam ser utilizados juntos, onde uma
mensagens sinaliza o agregado, de modo \textit{statefull} de ponta a ponta e a
outra mensagem sinalizando a cada nó, verificando disponibilidade do link.

O modelo com ambas sinalizações de modo concomitante foi uma proposta inicial para desenvolvimento de um modelo de
sinalização a ser utilizado em domínios \textit{DiffServ}. Esta proposta seria
feita sobre o NSIS da Universidade de Goettingen. O NSIS oferece suporte nativo
a mensagens em domínio \textit{DiffServ}, permitindo sinalização por classe de
serviço.

O NSIS poderia complementar a arquitetura \textit{DiffServ}, aplicando por
classe de classificação, onde nas bordas do domínio utilizaria um controle de
admissão. O modelo permitiria a entidade no \textit{DiffServ} sinalizar os
pedidos de reserva na borda para o final. Em seguida uma segunda sessão de fluxo
de tráfego é iniciada passando a especificação do fluxo em cada nó. Ao final, as
mensagens se agregam e a sinalização continua.

Feito um estudo inicial, a implementação deste modelo exigira alteração nas
classes do ciente NSIS, nsis-qosd, e na máquina de estados do NSLP, QoSFSM. Isto
porque o protocolo  oferece suporte para múltiplas sinalizações e agregação de
mensagens.

Deste modo seria adicionado uma identificação da sessão destas sinalizações, a
qual seria comparada no nó de borda, para identificação da mensagem. O servidor
de QoS do NSIS deveria então entender e gerar uma identificação para esta
mensagem, e a máquina de estados, entender e associar ao estado da mensagem,
este novo campo.

A não utilização dos campos atuais de identificação de mensagem foi estudada,
e, ao gerar dois fluxos de sinalização, o NSIS trata cada fluxo como uma sessão
diferente. Esta proposta poderá ser utilizada em domínios \textit{DiffServ}, com gerência
de recurso. Cita-se este modelo como projeto futuro.